Fix caller transaction graph handoff - #367

Resolves all 5 line comments from the automated review of the caller-mode
df.start() transaction-handoff fix:

1. HIGH: snapshot-visibility race after pg_xact_status() reports "committed".
   Postgres can mark a transaction committed before ProcArrayEndTransaction
   removes it from the running set used by a fresh snapshot, so an immediate
   re-read could misclassify a valid graph as CommittedMissing. Now checks
   pg_visible_in_snapshot(origin_xid, pg_current_snapshot()) first and
   retries until the xid is snapshot-visible before trusting a re-read.

2. HIGH: fixed 2s deadline could livelock a valid graph load (role
   validation + up to MAX_GRAPH_NODES rows + serialization). Graph loading
   now uses its own GRAPH_LOAD_QUERY_TIMEOUT (20s client-side) plus
   Postgres-side statement_timeout/lock_timeout backstops, decoupled from
   the short TRANSACTION_PROBE_QUERY_TIMEOUT used for cheap visibility and
   transaction-status probes.

3. HIGH: permanent database errors retried forever. Added SQLSTATE
   classification (classify_sqlstate/classify_sqlx_error): an allowlist of
   genuinely transient codes (connection failures, serialization/deadlock,
   our own statement/lock timeouts, admin-cancel/recovery conflicts) retries
   as before; everything else (insufficient_privilege, undefined_table,
   undefined_function, schema/decode errors, ...) now fails the activity
   immediately with its SQLSTATE embedded. Also added a bounded transient
   retry budget (MAX_GRAPH_RETRY_ATTEMPTS) tracked independently from the
   caller-transaction wait counter, so transient DB failures can no longer
   poll indefinitely even when individually "retryable".

4. MEDIUM: the regression test didn't prove the timeout-retry path
   executed and could pick an unrelated backend by pid alone. Rewrote
   68_long_caller_transaction.sql to identify the graph-probe backend by
   its exact query text, and to require a strictly later query_start
   (rather than a different pid, since the management pool may legitimately
   reuse a connection) for both the post-kill retry and a further,
   independent timeout-driven retry before the lock is released. Also fixes
   a real bug found while validating this test: pg_stat_activity's
   snapshot is cached for the lifetime of the enclosing transaction, so a
   long-lived DO block must call pg_stat_clear_snapshot() before every poll
   to observe live backend state.

5. LOW: false OR NULL evaluates to NULL in PL/pgSQL, so a NULL
   engine_output on failure bypassed the rollback assertions. Added
   engine_output IS NULL OR ... to both rollback checks.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

- Move the caller-transaction handoff changelog entry to the 0.2.8
  Unreleased section after rebasing onto origin/main.
- Apply server-side statement_timeout/lock_timeout to every cheap probe
  (visibility, transaction-status, snapshot) and the role superuser check
  so a blocked probe is cancelled by PostgreSQL and its connection returned
  cleanly to the pool instead of pinning a management connection.
- Durably retry terminal df.instances status writes (completed/failed)
  with a bounded budget so a transient management-plane outage cannot leave
  the row non-terminal while the engine execution is terminal.